Conventional container technology uses so-called namespaces, a resource scoping mechanism that provides a level of isolation against neighbor containers. Collaboration of containers happens through well-defined interfaces. For example, each container can offer an interface, like a REST API, for providing services.
Today's application environments tend to use containers and microservices as an architectural paradigm. In that scheme, a particular selection of microservices running as containers are grouped together in a pod, thereby forming, for example, an application or solution. Communication between these containers running as a group in a pod is thus optimized through co-location, such that no physical network traffic is used.
One of the most popular container orchestration projects, kubernetes, uses a grouping mechanism to place interacting services next to each other. Technically, using container co-location allows for maximum efficiency in communication. To achieve this, namespaces can be shared across containers. That is, communication between two containers with shared namespaces is very much more efficient than without namespace sharing, e.g., shared namespaces allow for loopback communication, which is significantly more efficient than using the default container networking communication infrastructure, which employs virtual switches.
However, if a container running in a first pod with a first namespace requires the services of a second container running in a second pod with a second namespace, or in other words, if the services of the second container are to be shared between the two pods with different namespaces (i.e., no namespace sharing between these two containers), the two containers are not co-located and communication between the two containers requires logical or even physical network traffic, governed for example, by TCP/IP. Although using network traffic via TCP/IP to enable shared services between two pods may be used, this solution does not leverage intra-pod communication for optimizing communication.
One solution is to break up the shared service, such that an instance of the service is run in each pod, however this solution also requires changes in application breakdown, which is difficult to implement.